Incidents were traced to changed or missing identifiers, stale attribute values, bulk attribute misconfigurations, version mismatches between published and current items, and automation selection logic that included orphan or legacy records. Resolutions across cases included: corrected source identifiers and attribute mappings so downstream systems referenced intended entities; repaired missing Employee‑ID and curriculum‑ID values and their database mappings so historical dashboards, payouts and course bookings reconciled; removed orphan or empty process entries in BIC Process Design and removed legacy opportunities or outbound tasks so automated jobs stopped listing or dialing deprecated contacts; executed vendor or bulk updates to correct cohort weighting and other misconfigured attributes; reissued template sends and regenerated documents after role/recipient identifiers were corrected; reassigned mis‑tagged exam papers and reprocessed results once subject/paper mappings were fixed; and corrected invalid academic‑term/semester values so document‑generation validations passed. For assessment import/version problems, teams reverted the relevant items in Jolt to the original published item versions, performed the import, then restored the items to their current versions so result mapping matched the published exam. Where automation caused regressions, selection logic and scheduled jobs were adjusted to exclude cancelled or already‑published records (for example preventing scheduled jobs from re‑entering published grades and changing publication timestamps). In cases where missing grade records caused runtime failures, incident traces showed GradeNotFoundException in Simovative service layers; resolutions in similar incidents involved restoring missing grade entries or updating bulk‑action selection logic to skip records without grades, and escalating code fixes to application owners when required. Where central support lacked permissions to change attributes in vendor systems, changes were escalated to the product owner or vendor and recorded as completed after the external update. Affected records were reprocessed, re‑sent, or reporting extracts regenerated as appropriate so downstream reports aligned with expected datasets.

Remediations corrected data, configuration and application logic so UI content, filtering, views and calculations were restored across Competency App, PMS/Dataverse, Quercus, Power Apps/SharePoint integrations, Viva Goals and Power BI reporting. Key outcomes and remedial work included:

Each change was deployed where applicable and impacted screens, records and downstream processes were validated after remediation. Incidents without a definitive local fix were escalated to the owning product or vendor teams with captured diagnostics and reproduction notes.

Incidents were resolved by addressing three distinct root causes:

Access and functionality were restored by locating the authoritative entitlement, tenant mapping, ownership, quota, feature flag or responsible team, applying the corresponding entitlement/ownership/quota/feature/licensing change (or escalating to the application owner), and ensuring affected identities re‑authenticated so UI and integrations reflected updates. Representative resolved scenarios included:

Across incidents, the consistent remediation pattern was: identify who owned the entitlement/tenant/mapping/artifact (or the responsible app/team), apply or coordinate the entitlement/ownership/quota/feature/licensing change or have the app owner deliver required artifacts, and ensure affected identities re‑authenticated so UI and integrations reflected the updated rights. Support agents provided owner/contact guidance and escalated to application or vendor owners when the application was outside local support scope.

Incidents were resolved by clearing or replacing stale client state and renewing expired credentials, and by targeted server-side fixes or specialist escalations when client-side fixes did not persist. Power BI Desktop sign-in and dataflow access were repeatedly restored in many cases after clearing the local credential cache, signing out, restarting the client, and performing a fresh sign-in which produced valid tokens. Power BI service scheduled-refresh failures that showed 'The refresh token has been expired due to inactivity' were fixed by renewing/replacing dataset OAuth credentials in the service or republishing datasets so the service obtained fresh refresh tokens; mixed-source datasets (SharePoint, Azure SQL, DWH) were commonly involved. Embedded and Marketplace report render/display failures were frequently recovered by browser reloads, hard-reloads, clearing cache/cookies, or using incognito sessions; when reloads did not persist, service- and client-version metadata plus activity/request/correlation IDs and cluster URIs were recorded and used to correlate frontend failures to backend incidents. Analytics discrepancies (e.g., Twilio vs Power BI) were resolved by reconciling source records (Twilio and Salesforce) against the Power BI dataset and performing corrective refreshes. Contact-center/outbound-calling clients sometimes recovered after browser hard-reloads, synthetic/dummy calls, or administrative task removals; persistent stuck or repeated calling, callback loops, and profile/queue mismatches were remedied by server-side developer fixes. External API token delivery issues (for example Freshdesk) were resolved by regenerating and delivering new API tokens and confirming account identifiers. Notably, some Power BI Desktop cases persisted despite clearing credentials and exhibited no stored credential entries under Global permissions; those required collection of diagnostic IDs (activity/request/correlation), service and client versions, and escalation to service or product teams for deeper investigation.

The templates were edited in the template editor: each affected template was opened with the 'Edit…' option and the 'Attachments' area was used to replace the associated PDF. During template editing, conditional paragraphs were reviewed and cycled to ensure all variations containing the bank details were updated. After replacing the PDFs and updating conditional content, the corrected bank name appeared on MyLIBF direct-debit forms and on generated invoice PDFs.

Support triaged these incidents as application-side loading failures and routed ownership to the respective application or service teams; IT support did not apply application-side fixes. When browser consoles displayed repeated 404s for frontend assets or source-map files, investigations found missing frontend resources in TEAQ/sitefusion and remediation was performed by the TEAQ/application team. Embedded third-party apps (for example Trello via LearnApp) were referred to the owning service desk (LCC) when no console errors were present. The Channel Switch/WhatsApp incident was part of a larger WAPP outage; the WAPP specialist team performed a cleanup that cleared the persistent “Loading” state and affected session IDs were collected for further cleanup. In an exam-management (Charly-App) incident the issue was partially resolved by examination administration while working directly with the user; IT recorded standard client-side troubleshooting suggestions (try a different browser, clear the browser cache) for recurrence. Tickets were closed after ownership by the owning application or service team was established.

Support investigated and confirmed the behavior was intentional: WhatsApp Business enforces a 24-hour reply window for conversations. The case was closed after the user was informed of the restriction, provided with an explanatory instruction document, and asked to supply the Task SID if the problem recurred under different conditions.

The vendor evaluation and planned migration were cancelled after a decision was made to remain on Viva Goals and to move OKR tracking to Excel later. The RfP/implementation work and any IT involvement were therefore not carried out; the request was closed as 'Won't Do' / 'Cancelled due to stay in Viva Goals' and recorded accordingly.

The incidents were resolved by increasing the sending quota on the affected CleverReach account(s). In one case the quota was raised to accommodate a requested 130,000 emails for Customer No. 87047 (service comment recorded 2024-02-13 14:20) and the request was closed after the change. In a separate case the user-reported 'Account-Limit' error was cleared after the account quota was increased (service comment recorded 2023-09-20 08:14), after which email sending resumed.

Users contacted WhatsApp Support to request a review of the enforcement action. In cases where a phone number was blocked for alleged commerce/trading policy violations, WhatsApp Support lifted the block and the user completed WhatsApp Business verification and regained access. In cases of repeated temporary suspensions/‘under review’ states that recurred when sending messages, WhatsApp Support similarly reviewed the account and restored access; access remained functional after Support intervention. When the WhatsApp Business number was provisioned through a Business Solution Provider (for example, Twilio), the support engagement included coordinating with the BSP and, where necessary, internal Sales Operations to escalate with WhatsApp. These support escalations resolved both permanent blocks and recurring temporary suspensions for affected users.

A program‑level decision retired Monday.com for Program Management; the program manager announced the planned replacement/retirement, began deactivating Monday accounts for users who had not arranged an alternative, and a team‑wide Monday rollout was not pursued. Related requests were triaged and handled individually: a Salesforce→Monday integration request was escalated to Applications & Requirements, a meeting was scheduled and stakeholders (Salesforce contact and Monday board owner) were recorded because no internal implementer was available. A spreadsheet/planning‑app inquiry was closed after IT recommended using existing Jira/Confluence planning functionality rather than approving a new spreadsheet application. A request for a marketing/MarTech tools inventory was directed to the MarTech owner (Milorad Milicic) to produce a complete inventory by the stated deadline. A vendor evaluation for a “mystery coffee” pairing tool captured functional requirements and constraints (remote pairing, group/subteam support, configurable frequency, optional calendar integration), noted no suitable native Microsoft product and no internal development capacity, and left data‑protection, licensing and ownership responsibilities as open issues while vendor options and trials were evaluated. A CMS/knowledge‑management recommendation request was recorded with a detailed feature and integration list (clear navigation; social features such as like/follow/share/comment and automatic updates; search and most‑viewed lists; Help Center; AI capabilities for notifications, relationship detection and similar‑content suggestions; integration/sync with Teams, Confluence, SharePoint and Salesforce; ability to publish/sync content into SharePoint; and separate internal/external surfaces). That CMS inquiry was treated as a tooling‑selection and governance item, escalated to MarTech/knowledge‑management and enterprise‑licensing stakeholders to confirm existing licensed products and assess gaps, and had data‑protection, publishing/sync mechanics, licensing and ownership questions recorded as unresolved while product options were evaluated.

Support investigated and applied a backend fix to the video assignment/provisioning service. After the fix was deployed, the user retried the operation and the CeMAP 2 & 3 videos were assigned successfully.

The Dataverse Solution was imported into the IU production environment using the cpc serviceAccount; the import was initiated and completed by Naumann. Requesters and testers verified the solution functionality post-import. Operators documented that Dataverse platform versions differed across environments and planned a platform update in a future maintenance window.

Support increased the templates limit to 100 and deployed a live fix to the template management service. After the deployment, multiple MSD users confirmed the ms_ds_afterfirstcall template was visible again.

The incidents were resolved by addressing multiple root causes uncovered across the dialer and intake workflows. First, the dialer/task-assignment subsystem was corrected to implement the intended task-lock behavior so already-processed tasks were not re-queued or restarted. Second, a unit-spanning routing/queue bug in the POB intake/dispatch routing was fixed (code and configuration changes) to stop cross-unit reassignments that caused continuous redial loops. Third, where duplicate presentations originated from a specific Power Outbound account, that account was deactivated which stopped recurring presentation of the same follow-ups/opportunities. The combined fixes were validated in pilot-site tests (which showed reduced duplicate calls), deployed to production, and confirmed to stop the repeated-call and re-presentation behavior. Prior to deployment, users had been advised to pause processing when identical tasks reappeared.

IT support triaged the report and determined the failure was outside IT's responsibility. Users were directed to file a request with the IU Reporting Tool team via Jira Service Management; the IT ticket was closed (Resolution: Done).

Support applied an update/fix to the EPOS system and asked the user to retest on 2025-09-23. After the fix was deployed there were no further error reports and the ticket was closed as resolved on 2025-10-02. No additional diagnostic details were recorded in the ticket.

Support staff responded that there was no dedicated Jira/Atlassian account manager or embedded consultant assigned. Ownership and responsibility for most Atlassian tooling resided with the Applications & Requirements department. Requesters were directed to submit general or specific usage and configuration questions via the service portal; the Applications & Requirements team handled incoming queries and provided advice on a case-by-case basis rather than through a named external account manager.